Amazon GuardDutyを導入する前に知っておきたいこと
Amazon GuardDutyは、悪意のある操作や不正な動作を継続的にモニタリングする脅威検出サービスです。AWS CloudTrail、Amazon VPC フローログ、DNS ログをデータソースに利用します。GuardDutyに興味がある方に向けて、GuardDutyでできることや、料金、実運用について紹介します。GuardDutyはコストパフォーマンスの良く導入障壁もほとんどない大変素晴らしいサービスです。
GuardDutyを有効にすることで、不審なアクティビティに気づける
GuardDutyを有効化しておくと、AWS上の不審なアクティビティに気づくことができます。既存の通信やパフォーマンスへの影響は一切ありません。検知できる内容はこちらをご覧ください。ざっくりと、EC2関連とIAM関連のFindingがあります。いくつか例を紹介します。Findingとは、GuardDutyが発見したセキュリティに関する問題です。
GuardDutyコンソールの雰囲気はざっくりと以下のような雰囲気です。Findingの一覧が表示されており、Findingを選択することで詳細を確認できます。
EC2関連ではスパムメールを送信していることなどに気づける
Backdoor:EC2/Spambotは、EC2が25番ポートでリモートホストと通信して通常と異なる動作をしていることを示します。今までメール送信をしたことがないEC2がメール送信をすると、Findingが発生します。EC2がマルウェアに感染し、スパムメールを送信している可能性があります。Findingが発生した場合は、侵害されたEC2 インスタンスの修正を参考に対応します。
Finding中のResource roleに注目します。TARGETの場合、EC2は被害者です。以下の例ではTARGETであり、外部からEC2に22番ポートへのアクセスがあった旨がわかります。ACTORの場合、EC2がマルウェアに感染し、外部サーバーに迷惑をかけている可能性が浮上します。
IAM関連のFinding
Recon:IAMUser/MaliciousIPCallerはAPIが既知の悪意のあるIPアドレスから呼び出されたことを示すFindingです。侵害されたAWS認証情報の修正を参考に、問題ないユーザーのアクセスかを確認します。問題がある場合は、パスワード変更、アクセスキーの無効化などを行います。
GuardDutyの導入フロー
全リージョンでの有効化
GuardDutyは全リージョンでの有効化が推奨されています。CloudFormation StackSetsを使えば、簡単にマルチリージョンの設定ができます。StackSetsでGuardDutyの有効化と通知設定する方法が、以下のブログで紹介されています。
AWS CloudTrail、Amazon VPC フローログ、DNS ログは有効にしなくても利用できます。
Q: Amazon GuardDuty の AWS CloudTrail、VPC フローログ、および DNS ログを有効にする必要はありますか?
Amazon GuardDuty は、AWS CloudTrail、VPC フローログ、AWS DNS ログから独立したデータストリームを直接取得します。Amazon S3 バケットポリシーを管理したり、ログを収集して保存する方法を変更したりする必要はありません。GuardDuty のアクセス許可は、サービスにリンクしたロールとして管理されます。これは GuardDuty を無効にすることで、いつでも取り消すことができます。このため、複雑な設定を行うことなく、簡単にサービスを有効にでき、AWS IAM アクセス許可の変更や S3 バケットポリシーの変更がサービスの運用に影響を与えるリスクが排除されます。また、大量のデータを消費する際にほぼリアルタイムで GuardDuty を極めて効率的に活用するため、アカウントやワークロードのパフォーマンス、または可用性に影響を与えることはありません。
CloudWatch Eventsで通知設定を行う
GuardDutyでFindingが発生すると、CloudWatch Eventsルールが発火します。上記のブログでは、Eventsルールが発火したら、Amazon SNSに繋げることでメール通知しています。Lambdaに繋げることで、backlogに通知したり、AWS Chatbotに繋げることでSlackに通知できます。GuardDutyのFindingが発火してから放置してしまってはGuardDutyを導入した意味が薄れるので、Slackや普段使っているチケット管理システムへの連携がおすすめです。
調査に利用できるサービスも一緒に有効化しておく
CloudTrailログ、VPCフローログを有効化しておきます。IAMキーの漏洩が疑われるケースでは、CloudTrailを確認し不正に実行されたAPIを洗い出します。EC2がマルウェアに感染しスパムメールを送っている可能性があれば、VPCフローログを確認しいつからSMTP通信が何件行われたのか確認します。たまったログはAmazon Athenaで確認すると便利です。
可能であればEC2に変更監視のソフトウェアをインストールしておきましょう。Trend Micro Deep Securityの変更監視では、重要なシステム領域やファイルを監視し、ベースラインとの比較を行います。GuradDutyのイベント発生前に、ファイルが変更された記録があれば調査に役立つかもしれません。
テストのためのイベントを発生させる
CloudWatchイベントが正しく発火して通知されるのか確認するために、テストイベントを発生できます。
ボタンをポチッと押し、結果サンプルを作る
コンソールから"結果サンプルの生成"ボタンを押すだけで、サンプルイベントを発生させます。
自分のIPアドレスを脅威リストに登録する
自分のIPアドレスを脅威リストに登録することで、イベントを発生させることもできます。
Findingによってはテスト方法が用意されている
Backdoor:EC2/C&CActivity.B!DNSの場合は、guarddutyc2activityb.comにクエリすることで、テストできます。
料金
30日間無料枠を活用する
GuardDutyの料金はログの量に依存します。一括請求（コンソリデーティッドビリング）を使っているとサービスによっては無料枠が使えないケースがありますが、GuardDutyの無料枠は一括請求時でも適用されます。1ヶ月無料枠で試して無効にするか検討すると良いでしょう。コンソールからログの量や推定料金を確認できます。
弊社では何千ものAWSアカウントを管理していますが、ここからGuardDutyの利用費の割合を算出しました。GuardDutyはAWS利用費全体のうち、85%以上のアカウントで1%以下の料金でご利用いただいています。そして、95%以上のアカウントで2%以下の料金で利用いただいています。参考までに私の検証アカウントでは、1月は1.7ドル。12月も1.7ドルでした。
実際に受け取った通知
私がGuardDutyと関わる中で実際に受け取ったFindingを紹介します。
UnauthorizedAccess:IAMUser/ConsoleLogin
よく発生するFindingです。いつも使っていないクライアントやIPアドレスからAWSコンソールに接続すると、UnauthorizedAccess:IAMUser/ConsoleLoginが発生します。普段会社からAWSコンソールにログインしている環境で、自宅からコンソールログインすると発火することがあります。FindingにIAMユーザー名が記録されるので、IAMユーザーの所有者が確認します。
Recon:IAMUser/ResourcePermissions
よく発生するFindingです。IAMユーザーでいつもしていない操作を行うと発火します。デフォルトの重大度は"中"です。EC2で作成された一時的なクレデンシャル情報を使用してAPIが呼び出された場合、結果の重大度は"高"になります。FindingにIAMユーザー名が表示されるので、Findingが発火した場合は担当者がアーカイブします。
Backdoor:EC2/Spambot
スパムメールを送信している可能性を示すFindingです。起動してからしばらく経ったEC2でメール送信した時に本Findingが発生しました。起動してすぐのEC2でメール送信しても、発生しません。関係者でテスト用にメール送信していること共有されていたため、誤検知だと気づくことができました。誤検知かの判断かが難しい場合は、VPCフローログを確認しメール送信がいつから行われているか確認したり、アンチマルウェアソフトでEC2をフルスキャンしマルウェアに感染していないか確認することになるかと思います。
Recon:EC2/PortProbeUnprotectedPort
EC2のセキュリティグループで、httpを0.0.0.0/0で許可した環境で、Recon:EC2/PortProbeUnprotectedPortが発生しました。ELBを使っている環境だったため、httpはELBからのみ許可することでイベントが発生しなくなりました。
Policy:IAMUser/RootCredentialUsage
ルートクレデンシャル情報を使った場合に、発火します。ルート情報の利用は最小限にします。心当たりがあるのであればイベントの発生自体は問題ありません。プログラム中にルートクレデンシャルを埋め込んでいる場合は、IAMキーへの変更を行います。AWS CloudTrail ログのクエリを参考にルートキーの使用状況を確認するといいでしょう。S3への接続については、CloudTrailのS3バケットのオブジェクトレベルのログ記録を有効にしないとログに残らないので気をつけてください。
Behavior:EC2/NetworkPortUnusual
Resource roleがACTORで発生しました。通常と異なるポートでリモートホストと通信していることを示すイベントです。状況を確認したところ、リモートホストのIPアドレスやポート番号に心当たりがない状況に当たりました。つまり、マルウェアに感染した可能性が出てきました。 手っ取り早いのは、EC2を停止または隔離する対応です。 EC2を停止すればマルウェアの感染が広がるリスクやマルウェアの活動を停止できます。
侵害されたEC2インスタンスの修正に基づき、最新のアンチマルウェアをインストールし、フルスキャンを実施しましたが、検知しませんでした。 アンチマルウェアが検知できないのか、GuardDutyが誤検知したのかなど様々な可能性があり、安心できない状況でした。 また、検知したリモートホストと継続的に通信が行われていないのか気になりました。単発的な事象なのか、継続的に発生している事象なのか気になったわけです。
そこで、脅威リストを使ってみることにしました。継続的にリモートホストと通信が発生している場合、脅威リストに登録すればイベントが発生すると考えたためです。 登録の結果、FTPの通信を大量に検知しました。 FTPについて考えたところ、ホストに心当たりがありました。 イベントが発生した原因として、DNS名に紐づくIPアドレスが変更された可能性や、FTPのパッシブポートがたまたまいつも使われていない範囲で使われたと推測しています。いずれにせよ、不明なホストではなく、システムと連携しているホストと通信していたことを確認できました。
重要度の高いFindingにすぐに対応できるように通知する
GuardDutyでイベントが発生したら、担当者を割り当て対応します。そのため、GuardDutyの通知はチケット管理システムやSlackのようなチャットに連携すると良いかと思います。イベントには低、中、高の重要度があります。高については、できるだけ速やかに確認すると良いでしょう。severityの値は0.1～8.9の範囲で、値0と9.0から10.0は将来の予約用に確保されています。Findingによってデフォルトの重大度は決まっていますが、Findingの内容によって重要度が高くなることもあります。
- 低：severityパラメータの値が0.1〜3.9
- 中：severityパラメータの値が4.0〜6.9
- 高：severityパラメータの値が7.0〜8.9
GuardDutyの検知は賢いため、1日になんども通知が発生するといったことはあまりないはずです。とはいえ、前述のようによく発生するイベントが運用上のノイズになる場合や一時的に通知を止めたいケースがあるかと思います。通知を抑制する方法を3つご紹介します。
自動アーカイブでCloudWatch Eventsの発火を抑制
GuardDutyではリソース、Finding Typeなどでフィルタを作り、フィルタに一致する場合は自動アーカイブできます。自動アーカイブされたFindingはCloudWatch Eventsが発火しません。
信頼できるIPリストでホワイトリストを作る
信頼できるIPリストを使えば、IPアドレスのホワイトリストを作成できます。ホワイトリストに登録されると、Findingは発生しません。
おわりに
Amazon GuardDutyを導入する前に知っておきたいこととして、GuardDutyでできることや、料金、実運用について紹介しました。
